ETSITS132 274V9.0.0 



(2010-02) 



Technical Specification 

Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

LTE; 

Telecommunication management; 

Charging management; 

Short Message Service (SMS) charging 

(3GPP TS 32.274 version 9.0.0 Release 9) 



33i^ 





3GPP TS 32.274 version 9.0.0 Release 9 1 ETSI TS 1 32 274 V9.0.0 (201 0-02) 



Reference 



RTS/TSGS-0532274V900 
Keywords 



GSM, LTE, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2010. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 32.274 version 9.0.0 Release 9 2 ETSI TS 1 32 274 V9.0.0 (201 0-02) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 32.274 version 9.0.0 Release 9 3 ETSI TS 1 32 274 V9.0.0 (201 0-02) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 7 

4 Architecture considerations 8 

4.1 High level SMS architecture 8 

4.2 SMS offline charging architecture 8 

4.3 SMS online charging architecture 8 



5 SMS charging principles and scenarios 

5.1 SMS charging principles 

5.1.1 General principles 

5.1.2 Segmentation and concatenation 

5.1.3 Triggers for generation of charging information 

5.2 SMS offline charging scenarios 1 

5.2.1 Basic principles 1 

5.2.2 Rf message flows 1 

5.2.3 CDR generation 1 

5.2.3.1 Triggers for xxx-CDR charging information collection 1 

5.2.3.2 Triggers for xxx-CDR Charging Information Addition 1 

5.2.3.3 Triggers for xxx-CDR closure 1 

5.2.4 Ga record transfer flows 1 

5.2.5 B^^ CDR file transfer 1 

5.3 SMS online charging scenarios 12 

5.3.1 Basic principles 12 

5.3.2 Ro message flows 12 

5.3.2.1 Simple Submission 12 

5.3.2.2 Enhanced Submission 13 

5.3.2.3 Delivery Report 13 

5.3.2.4 Origination retry 13 

5.3.2.5 Termination charge 15 

5.3.2.6 Termination charge retry 17 

5.3.2.7 Unsuccessful transaction 19 

5.3.2.8 IMS/SMS Interworking Messages Charging 21 

5.3.2.9 Simple Submission with SM service request 23 

5.3.3 Credit Control related 24 

5.3.3.1 Triggers for stopping for an SMS Credit Control session 24 

5.3.3.2 Triggers for providing interim information for a SMS Credit Control session 24 

6 Definition of charging information 25 

6.1 Data description for SMS offline charging 25 

6.1.1 Rf message contents 25 

6.1.1.1 Summary of Offline Charging Message Formats 25 

6.1.1.2 Structure for the Accounting Message Formats 25 

6.1.1.2.1 Accounting-Request Message 25 

6.1.1.2.2 Accounting- Answer Message 25 

6.1.2 Ga message contents 25 

6.1.3 CDR description on the B^x interface 25 

6.2 Data description for SMS online charging 26 

6.2.1 Ro message contents 26 



£75/ 



3GPP TS 32.274 version 9.0.0 Release 9 4 ETSI TS 1 32 274 V9.0.0 (201 0-02) 

6.2.1.0 General 26 

6.2.1.1 Summary of Message Formats 27 

6.2.1.2 Structure for the Credit Control Message Formats 27 

6.2.1.2.1 Debit/Reserve Units Request Message 27 

6.2.1.2.2 Debit / Reserve Units Response Message 28 

6.3 SMS charging specific parameters 29 

6.3.1 Definition of the SMS charging information 29 

6.3.1.1 SMS charging information assignment for Service-Information 29 

6.3.1.2 Definition of the SMS Information 30 

6.3.2 Formal parameter description 31 

6.3.2.1 SMS charging information for CDRs 31 

6.3.2.2 SMS charging information for charging events 31 

Annex A (informative): Change history 32 

History 33 



£75/ 



3GPP TS 32.274 version 9.0.0 Release 9 5 ETSI TS 1 32 274 V9.0.0 (201 0-02) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 
3GPP TS 32.240 [2], which provides an umbrella for other charging management TSs that specify: 

• the content of the CDRs per domain / subsystem / service (offline charging); 

• the content of real-time charging messages per domain / subsystem / service (online charging); 

• the functionality of online and offline charging for those domains / subsystems / services; 

• the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or 
charging events). 

The complete document structure for these TSs is defined in 3GPP TS 32.240 [2]. 

The present document specifies the Offline and Online Charging description for the Short Message Service (SMS), 
based on the functional description in 3GPP TS 23.040 [7] and on the SMS over IP in 3GPP TS 23.204 [8]. The present 
document does not replace existing offline SMS charging functionality and therefore is in addition to that defined in 
3GPP TS 32.250 [9] and 3GPP TS 32.251 [10]. This charging description includes the offline and online charging 
architecture and scenarios specific to SMS, as well as the mapping of the common 3GPP charging architecture specified 
in 3GPP TS 32.240 [1] onto SMS. It further specifies the structure and content of the CDRs for offline charging, and the 
charging events for online charging. The present document is related to other 3GPP charging TSs as follows: 

• The common 3GPP charging architecture is specified in 3GPP TS 32.240 [2]; 

• The parameters, abstract syntax and encoding rules for the CDRs are specified in 3GPP TS 32.298 [3]; 

• A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [6]; 

• The file based mechanism used to transfer the CDRs from the network to the operator"s billing domain (e.g. the 
billing system or a mediation device) is specified in 3GPP TS 32.297 [5]; 

• The 3GPP Diameter application that is used for SMS offline and online charging is specified in 3GPP TS 32.299 
[4]. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22. 115 [102]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 
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Record (CDR) parameter description". 
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Messaging Service (MMS) charging". 
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Services (IMS) charging". 

[16] 3GPP TS 22.142: " Value Added Services (VAS) for Short Message Service (SMS) requirements " 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1], TS 32.240 [2] and the 
following apply. A term defined in the present document takes precedence over the definition of the same term, if any, 
in TR 21.905 [1] or TS 32.240[2]. 

SMS node: An SMS node, in this specification, refers to either an SMS router, IP-SM-GW, SMS-SC or a combination 
of these nodes. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1], TS 32.240 [2] and the following 
apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if 
any, in TR 21.905 [1] orTS 32.240 [2]. 
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Architecture considerations 



4.1 High level SMS architecture 

The high level SMS architecture is as defined in 3GPP TS 23.040 [7].Only the SMS Router, SMS-SC and the IP-SM- 
GW are within the scope of this specification. The details for the other nodes in the SMS architecture are defined within 
3GPP TS 32.250 [9] and 3GPP TS 32.251 [10]. 

4.2 SMS offline charging architecture 

Editor's Note: The offline architecture is For Further Study. 

4.3 SMS online charging architecture 

For online charging, the relevant SMS nodes utilise the Ro interface and appUcation towards the OCS as specified in TS 
32.299 [4]. The Ro reference point covers all online charging functionality required for SMS. 

The SMS online charging architecture is depicted in figure 4.3. 



SMS Router 



SMS-SC 



Ro 
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IP-SM-GW 











Ro 



T 



Online Charging System 



Figure 4.3: SMS online charging architecture 

Details on the interfaces and functions can be found in TS 32.240 [2] for the general architecture components, 
TS 32.296 [11] for the OCS, and 32.299 [4] for the Ro application. 



ETSI 



3GPP TS 32.274 version 9.0.0 Release 9 9 ETSI TS 1 32 274 V9.0.0 (201 0-02) 

5 SMS charging principles and scenarios 

5.1 SIVIS charging principles 

5.1.1 General principles 

The Short Message Service comprises 4 main operational scenarios: 

Person to Person: The message is sent by a UE as originator and received by a UE as destination. 

Person to AppHcation: The message is sent by a UE as originator and received by a third party appHcation as 
destination. 

Application to Person: The message is sent by a third party application as originator and received by a UE as 
destination. 

Application to Application: The message is sent by a third party application as originator and received by 
another third party application as destination. 

In addition SMS Nodes may apply services such as value added services specified in 3GPP TS 22.142 [16], services 
defined in industry standard protocols for SM submission from applications in a fixed network (protocols such as 
SMPP, UCP/EMI, OIS, CIMD, etc.) or vendor specific services as endorsed by 3GPP TS 23.040 [7]. 

As such, the SMS node collects charging information such as: 

the destination and source addresses applied for an SM; 

an indication of origination or termination handling; 

identification of the node(s) and connection(s) involved in the SM transaction; 

SM validity period; 

in scenarios involving an application / VASP, the charging information describes the identification of the 
application / VASP; 

requested SM service type. 

5.1 .2 Segmentation and concatenation 

Information about concatenated messages should be sent to the charging systems in order to apply the appropriate 
charging models. The charging system may be required to be stateful to process information about segmented messages. 

5.1 .3 Triggers for generation of charging information 

The following service level events shall, based on operator configuration, trigger the generation of charging 
information: 

Simple submission - based on reception at the SMS node. 

Enhanced submission - based on completion of the transaction handling at the SMS node. 

Origination retry - based on the enhanced submission where the initial handling fails and a redelivery attempt is 
initiated. 

Delivery report 

Termination - Application to Person scenario only. 

Termination retry - Application to Person scenario only - reattempt delivery of an SM to a terminating entity; 
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SM service request. 
Depending on the charging model applied, a "refund" may be necessary for unsuccessful delivery. 
See clause 5.3 for detailed procedures associated with the triggers above. 
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5.2 SMS offline charging scenarios 

5.2.1 Basic principles 

Editor's Note: For Further Study. 

5.2.2 Rf message flows 

Editor's Note: For Further Study. 

5.2.3 CDR generation 

5.2.3.1 Triggers for xxx-CDR charging information collection 

Editor's Note: For Further Study. 

5.2.3.2 Triggers for xxx-CDR Charging Information Addition 

Editor's Note: For Further Study. 

5.2.3.3 Triggers for xxx-CDR closure 

Editor's Note: For Further Study. 

5.2.4 Ga record transfer flows 

Editor's Note: For Further Study. 

5.2.5 Bxx CDR file transfer 

Editor's Note: For Further Study. 



ETSI 



3GPP TS 32.274 version 9.0.0 Release 9 



12 



ETSI TS 132 274 V9.0.0 (2010-02) 



5.3 SMS online charging scenarios 

5.3.1 Basic principles 

SMS online charging uses the Credit Control application as specified in 3GPP TS 32.299 [4]. 

SMS charging may use the Immediate Event Charging (lEC) principle or the Event Charging with Unit Reservation 
(ECUR) principle as specified in 3GPP TS 32.299 [4]. The chargeable events for subscriber charging are associated 
with SM transactions. 

An implementation may use either lEC or ECUR for charging events based on operator configuration. 

The units used for quota shall be service specific and based on an SM. 

The selection of the OCS is implementation specific as there is no guaranteed means of providing the OCS address to 
the CTF. 

In addition, SMS charging may use the Refund Account principle when the operation has not been successfully 
completed after an Immediate Event Charging (lEC). 

NOTE: For SMSIP, the IP-SM-GW may receive information relevant for online charging through signalling in 
IMS. 

5.3.2 Ro message flows 



5.3.2.1 



Simple Submission 



This clause contains message flows for the different operation models lEC (figure 5.3.2.1-1) and ECUR 
(figure 5.3.2.1-2). 
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1 . SM-Submit or Forward 
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2. Debit Units Request 
















3. Credit processing 




4. Debit Units F 


Response 






5. Forward-SM 



















Figure 5.3.2.1-1 : Online charging in simple submission for lEC 

1) Depending on which SMS mechanism (i.e. SMS or SMSIP) is in operation, the SMS node receives an incoming 
SM-Submit or a MAP-Forward-SM. 

2) The SMS node triggers a Debit Units Request message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Debit Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the origination procedures. 
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SMS Node 



1. SM-Submit or Forward-SM 



OCS 



2. Reserve Units Request (I nitial) 



3. Credit processing 



4. Reserve Units Response (Initial) 



5. Forward short message 



6. Forward short message i cknowledgement 



7. Reserve Units Request (Terminate) 



8. Credit processing 



9. Reserve Units Response (Terminate) 



Figure 5.3.2.1-2: Online charging in simple submission for ECUR 

1) Depending on which SMS mechanism (i.e. SMS or SMSIP) is in operation, the SMS node receives an incoming 
SM-Submit or a MAP-Forward-SM. 

2) The SMS node triggers a Reserve Units Request (Initial) message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Reserve Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the origination procedures. 

6) The SM transaction is successfully acknowledged. 

7) The SMS node triggers a Reserve Units Request (Terminate) message to the OCS reporting the successful event 
transaction. 

8) The OCS performs the appropriate credit processing based on the received request. 

9) The OCS responds with a Reserve Units Response message to the SMS node.. 



5.3.2.2 



Enhanced Submission 



The enhanced submission procedures are similar to the simple submission procedures using ECUR. However, the 
trigger for Reserve Units Request (Terminate) may be based on unsuccessful handling e.g. negative acknowledgement 
and with or without successful storage of the message for future redelivery attempts. See failure scenarios defined in 
clause 5.3.2.7. 



5.3.2.3 



Delivery Report 



The origination of delivery reports use the same procedures as the simple submission procedures as described within 
clause 5.3.2.1. The delivery report itself is contained within a new SM. 



5.3.2.4 



Origination retry 



This clause contains message flows for the different operation models lEC (figure 5.3.2.4-1) and ECUR 
(figure 5.3.2.4-2) for redelivery attempts in the origination direction. 
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Figure 5.3.2.4-1 : Online charging in origination redelivery attempt for lEC 

1) An SMS node internal trigger occurs to attempt a redelivery of a previously failed and stored SM. 

2) The SMS node triggers a Debit Units Request message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Debit Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the origination procedures. 
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3. Credit processing 
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(Initial) 
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9. Reserve Units Response 



(Terminate) 



Figure 5.3.2.4-2: Online charging in origination redelivery attempt for ECUR 

1) An SMS node internal trigger occurs to attempt a redelivery of a previously failed and stored SM. 

2) The SMS node triggers a Reserve Units Request (Initial) message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Reserve Units Response message to the SMS node. 
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5) If authorised, the SMS node continues the SM processing as appropriate for the origination or termination 
procedures. 

6) The SM transaction is successfully acknowledged. 

7) The SMS node triggers a Reserve Units Request (Terminate) message to the OCS reporting the successful event 
transaction. 

8) The OCS performs the appropriate credit processing based on the received request. 

9) The OCS responds with a Reserve Units Response message to the SMS node. 

5.3.2.5 Termination charge 



SMS Node 



1. SM-SUBMIT 



OCS 



2. Debit Units Request 



3. Credit processing 



4. Debit Units Response 



5. Standard SMS handhng 



Figure 5.3.2.5-1 : Online charging in termination for lEC 

1) The SMS node receives an incoming SM-SUBMIT from an application destined for a mobile recipient. 

NOTE: This scenario differs from simple submission charging as described in subclause 5.3.2.1 in that typically 
the mobile recipient (instead of originator or both parties) will be charged for such a short message. 

2) The SMS node triggers a Debit Units Request message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Debit Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the termination procedures. 
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Figure 5.3.2.5-2: Online charging in termination for ECUR 

1) The SMS node receives an incoming SM-SUBMIT from an application destined for a mobile recipient. 

NOTE: This scenario differs from simple submission charging as described in subclause 5.3.2.1 in that typically 
the mobile recipient (instead of originator or both parties) will be charged for such a short message. 

2) The SMS node triggers a Reserve Units Request (Initial) message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Reserve Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the termination procedures. 

6) The SM transaction is successfully acknowledged. 

7) The SMS node triggers a Reserve Units Request (Terminate) message to the OCS reporting the successful event 
transaction. 

8) The OCS performs the appropriate credit processing based on the received request. 

9) The OCS responds with a Reserve Units Response message to the SMS node. 
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5.3.2.6 



Termination charge retry 
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Figure 5.3.2.6-1 : Online charging in termination redelivery attempt for lEC 

1) An SMS node internal trigger occurs to attempt a redelivery of a previously failed and stored SM. 

2) The SMS node triggers a Debit Units Request message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Debit Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the termination procedures. 
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Figure 5.3.2.6-2: Online charging in termination redelivery attempt for ECUR 

1) An SMS node internal trigger occurs to attempt a redelivery of a previously failed and stored SM. 

2) The SMS node triggers a Reserve Units Request (Initial) message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Reserve Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the termination procedures. 

6) The SM transaction is successfully acknowledged. 

7) The SMS node triggers a Reserve Units Request (Terminate) message to the OCS reporting the successful event 
transaction. 

8) The OCS performs the appropriate credit processing based on the received request. 

9) The OCS responds with a Reserve Units Response message to the SMS node. 
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5.3.2.7 Unsuccessful transaction 

Unsuccessful transaction after lEC 

The following flow in figure 5.3.2.7-1 only applies where a refund action is required for unsuccessful delivery. 



SMS Node 

I 



ocs 



1 . Trigger to attempt 
delivery 



2. Debit Units Request 



3. Credit processing 



4. Debit Units Response 



5. Forward short message 



6. Forward short message NOK 



7. Debit Units Request (Refund Account) 



8. Credit Refund 



9. Debit Units Response (F efund Account) 



Figure 5.3.2.7-1 : Unsuccessful transaction after lEC 

1) The SMS node receives a trigger to attempt delivery of an SM. This may be for origination, termination or 
redelivery attempt. 

2) The SMS node triggers a Debit Units Request message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Debit Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for origination or termination 
procedures. 

6) The SM transaction is acknowledged as an unsuccessful transaction (either via explicit signalling or an internal 
trigger). 

7) The SMS node triggers a Debit Units Request (Refund Account) message to the OCS. 

8) The OCS performs the appropriate refund processing based on the received request. 

9) The OCS responds with a Debit Units Response (Refund Account) message to the SMS node. 
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Unsuccessful transaction in ECUR 



SMS Node 



I 



ocs 



1 . Trigger to attempt 
delivery 



2. Reserve Units Request (I nitial) 



3. Credit processing 



4. Reserve Units Response 



5. Forward short message 



6. Forward short message NOK 



7. Reserve Units Request (Terminate) 



(Initial) 



8. Credit processing 



9. Reserve Units Response 



(Terminate) 



Figure 5.3.2.7-2: Unsuccessful transaction for ECUR 

1) The SMS node receives a trigger occurs to attempt delivery of an SM. This may be for origination, termination 
or redelivery attempt. 

2) The SMS node triggers a Reserve Units Request (Initial) message to the OCS. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Reserve Units Response message to the SMS node. 

5) If authorised, the SMS node continues the SM processing as appropriate for the origination or termination 
procedures. 

6) The SM transaction is acknowledged as an unsuccessful transaction (either via explicit signalling or an internal 
trigger). 

7) The SMS node triggers a Reserve Units Request (Terminate) message to the OCS reporting the used unit for the 
service to zero. This characterizes the unsuccessful event transaction. 

8) The OCS performs the appropriate credit processing based on the received request. 

9) The OCS responds with a Reserve Units Response message to the SMS node. 
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5.3.2.8 



IMS/SMS Interworking Messages Charging 



This clause contains message flows for the different operation models lEC (figure 5.3.2.8-1) and ECUR 
(figure 5.3.2.8-2) for IMS/SMS Interworking messages in the origination direction. 



IP-SM-GW 



1. SIP MESSAGE 



OCS 



2. Parse the SIP MESSAGE 



3. Debit Units Request 



4. Credit processing 



5. Debit Units Response 



6. Convert the SIP MESSAGE to 
1 or n short messages 



7. Forward segmented shor 



messages 

► 



Figure 5.3.2.8-1 : Online charging in origination IMS/SMS Interworking IVIessages for lEC 

1) The IP-SM-GW receives an incoming SIP MESSAGE. 

2) The IP-SM-GW parses the SIP MESSAGE. 

3) The IP-SM-GW triggers a Debit Units Request message to the OCS. 

4) The OCS performs the appropriate credit processing based on the received Debit Units Request. 

5) The OCS responds with a Debit Units Response message to the IP-SM-GW. 

6) IP-SM-GW converts the SIP MESSAGE to 1 or n (n>=l) short messages. 

7) If authorised, the IP-SM-GW forwards the segmented short messages. 
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IP-SM-GW 



1. SIP MESSAGE 



OCS 



2. Parse the SIP MESSAGE 



3. Reserve Units Request (Initial) 



4. Credit processing 



5. Reserve Units Response 



6. Convert the SIP MESSAGE 
1 or n short messages 



7. Forward segmented shor 



9. Reserve Units Request (Terminate) 



(Initial) 



messages 



8. Forward segmented short messages acknowledgement 



10. Credit processing 



11. Reserve Units Respons(: (Terminate) 



Figure 5.3.2.8-2: Online charging in origination IMS/SMS Interworking Messages for ECUR 

1) The IP-SM-GW receives an incoming SIP MESSAGE. 

2) The IP-SM-GW parses the SIP MESSAGE. 

3) The IP-SM-GW triggers a Reserve Units Request (Initial) message to the OCS. 

4) The OCS performs the appropriate credit processing based on the received Reserve Units Request. 

5) The OCS responds with a Reserve Units Response message to the IP-SM-GW. 

6) IP-SM-GW converts the SIP MESSAGE to 1 or n (n>=l) short messages. 

7) If authorised, the IP-SM-GW forwards segmented short messages. 

8) All the short messages transactions are successfully acknowledged. 

9) The IP-SM-GW triggers a Reserve Units Request (Terminate) message to the OCS reporting the successful event 
transaction. 

10) The OCS performs the appropriate credit processing based on the received request. 
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ll)The OCS responds with a Reserve Units Response message to the IP-SM-GW. 

5.3.2.9 Simple Submission with SM service request 

This clause contains message flows for operation models lEC (figure 5.3.2.9-1) where application of a SM service is 
subject to charging independent from the SM submission. 

Editors Note; Simple SM submission with SM service request for operation model ECUR is FES. 







SMS Node 




OCS 




1. SM-SUBMIT 




















2. Debit Units Request 1 
















3. Credit processing 




4. Debit Units Response 1 














5. SM Service Requested 










6. Debit Units 


Request 2 
















7. Credit processing 2 




^. Debit Units F 


Response 2 














9. Service Application 










10. Forward 


-SM 





















Figure 5.3.2.9-1 : Online charging in simple submission with SIVI service request for lEC 

1) Depending on which SMS mechanism (i.e. SMS or SMSIP) is in operation, the SMS node receives an incoming 
SM-Submit or a MAP-Forward-SM which includes a SM service request (such as forwarding or SM copy). 

2) The SMS node triggers a Debit Units Request message to the OCS for the SM submission. 

3) The OCS performs the appropriate credit processing based on the received request. 

4) The OCS responds with a Debit Units Response message for the SM submission to the SMS node. 

5) If normal SM processing is authorized in step 4, the SMS Node analyzes the SM and detects that a SM service 
must be applied that is subject to charging. 

6) If a SM service subject to charging is detected in step 5, the SMS node triggers an additional Debit Units 
Request message to the OCS for the requested SM service. 

7) The OCS performs the appropriate credit processing based on the received request. 

8) The OCS responds with a Debit Units Response message for the requested SM service to the SMS node. 
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9) If authorised in step 7, the SMS node appHes the requested SM service. 

NOTE 1: Depending on the nature of the requested SM service, "service apphcation" may involve creating 

additional messages (for example in case of a SM copy service). This is deemed part of step 9 and not 
otherwise shown in this diagram. 

10) If authorised in step 4, the SMS node continues the SM processing as appropriate for the origination procedures. 

NOTE 2: Authorization of SM processing is independent of the authorization for application of a SM service. 
I.e. If authorization is for SM processing is granted in step 4 but authorization for SM service is 
refused in step 8 SM processing appropriate for the originating service continues without applying the 
requested SM service. 

5.3.3 Credit Control related 

5.3.3.1 Triggers for stopping for an SMS Credit Control session 

Used in ECUR only, a Debit / Reserve Units Request message to terminate the credit control session is sent to OCS 
when: 

- Validity time for granted quota expires 

Granted quota runs out (i.e. a successful event has occurred) 

Abort-Session-Request is received from the OCS 

The expiration of the validity time for quota does not require the SMS procedures to be terminated. The CTF shall be 
configurable as to whether on expiration of validity time, the service should be aborted or not; i.e. whether the stored 
message should be deleted and no further (re-)delivery attempt should be made. 

5.3.3.2 Triggers for providing interim information for a SMS Credit Control session 

The provision of interim information for credit control is not used in this release of the specification, due to the use of 
lEC and ECUR. 
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6 Definition of charging information 

6.1 Data description for SIVIS offline charging 

6.1 .1 Rf message contents 

6.1 .1 .1 Summary of Offline Charging Message Formats 

Editor's Note: For Further Study. 

6.1 .1 .2 Structure for the Accounting Message Formats 

6.1.1.2.1 Accounting-Request Message 

Editor's Note: For Further Study. 

6.1.1.2.2 Accounting-Answer Message 

Editor's Note: For Further Study. 

6.1 .2 Ga message contents 

Editor's Note: For Further Study. 

6.1 .3 CDR description on the Bxx interface 

Editor's Note: For Further Study. 
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6.2 Data description for SIVIS online charging 
6.2.1 Ro message contents 



6.2.1.0 



General 



The SMS node generates Debit / Reserve Units information that can be transferred from the CTF to the OCF. For this 
purpose, SMS onHne charging utiHses the Debit Units and Reserve Units procedure that is specified in the 3GPP Debit / 
Reserve Units operation in 3GPP TS 32.299 [4]. 

The SMS node generates refund information that can be transferred from the CTF to the OCF. For this purpose, it uses 
REFUND procedure defined in IETF RFC 4006 [12] with extended AVPs. 

The Debit / Reserve Units procedure employs the Debit / Reserve Units Request and Debit / Reserve Units Response 
messages. 

The Refund Account procedure employs the Debit Units Request (Refund Account) request and response messages. 

Table 6.2.1 describes the use of these messages for SMS online charging. 

Table 6.2.1 : SMS Online Charging Messages contents 



Command-Name 


Source 


Destination 


Debit / Reserve Units Request 


CTF 


OCS 


Debit / Reserve Units Response 


OCS 


CTF 



This clause 6.2.1 describes the different fields used in the credit control messages. 
Detailed descriptions of the fields are provided in 3GPP TS 32.299 [4]. 
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6.2.1.1 



Summary of Message Formats 



6.2.1.2 



Structure for tfie Credit Control Message Formats 



6.2.1.2.1 



Debit/Reserve Units Request Message 



Table 6.2.1.2.1 illustrates the basic structure of a Debit / Reserve Units Request message from SMS node as used for 
SMS online charging. 

Table 6.2.1 .2.1 : Debit / Reserve Units Request Message Contents for SMS 



Field 


Category 


Description 


Session Identifier 


M 


This field identifies the operation session. 


Originator Host 


M 


This field contains the identification of the source point of the operation. 


Originator Domain 


M 


This field contains the realm of the operation originator. 


Destination Domain 


M 


This field contains the realm of the operation destination. 


Operation Identifier 


M 


This field is a unique operation identifier. 


Operation Tol<en 


M 


This field contains the service context, i.e. SIVIS charging. 


Operation Type 


M 


This field defines the transfer type: event for immediate event based charging and 
initial, terminate for ECUR based charging. 


Operation Number 


M 


This field contains the sequence number of the transferred messages. 


Destination Host 


Oc 


This field contains the identification of the destination point of the operation. 


User Name 


Oc 


This field contains the identification of the source node. 


Origination State 


Oc 


Used for ECUR only. 


Origination 
Timestamp 


Oc 


This field contains the time when the operation is requested. 


Subscriber Identifier 


Om 


This field contains the identification of the subscriber (i.e. IVISISDN) that uses the 
requested service. 


Termination Cause 


Oc 


This field contains information about the cause for termination of a credit control 
session. Used for terminating credit control sessions in ECUR only. 


Requested-Action 


Oc 


This field contains the requested action, used for lEC only. 


IVIultiple Operation 


Om 


This field indicate the occurrence of multiple operations. Used for ECUR only 


IVIultiple Unit 
Operation 


Oc 


This field contains the parameter for the quota management. Used for ECUR only 


Subscriber 
Equipment Number 


Oc 


This field contains the identification of the user equipment used to access service. 
Included if information is made available to the node. 


Proxy Information 


Oc 


This field contains the parameter of the proxy. 


Route Information 


Oc 


This field contains the parameter of the route. 


Service Information 


Om 


This field holds the SMS specific parameter and is described in clause 6.3. 
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6.2.1.2.2 



Debit / Reserve Units Response Message 



Table 6.2.1.2.2 illustrates the basic structure of a Debit / Reserve Uirits Response message as used for SMS charging. 
This message is always used by the OCS as specified below, independent of the receiving SMS node and the operation 
type that is being replied to. 

Table 6.2.1 .2.2: Debit / Reserve Units Response Message Contents for SMS 



Field 


Category 


Description 


Session Identifier 


M 


This field identifies the operation session. 


Operation Result 


M 


This field identifies the result of the operation. 


Originator Host 


M 


This field contains the identification of the source point of the operation. 


Originator Domain 


M 


This field contains the realm of the operation originator. 


Operation Identifier 


M 


This field is a unique operation identifier. 


Operation Type 


M 


This field defines the transfer type: event for event based charging and start, 
interim, stop for session based charging. 


Operation Number 


M 


This field contains the sequence number of the transferred messages. 


Operation Failover 


- 


Not used for SMS in 3GPP. 


IVIultiple Unit Operation 


Oc 


This field contains the parameter for the quota management. Used in lEC for 
refund purpose and in ECUR. 


Operation Failure Action 


Oc 


This field defines the resulting operation at the SI\/IS node if a failure has occurred 
at the OCS for ECUR. 


Operation Event Failure 
Action 


Oc 


This field defines the resulting operation at the SMS node if a failure has occurred 
at the OCS for 1 EC. 


Redirection Host 


Oc 




Redirection Host Usage 


Oc 




Redirection Cache Time 


Oc 




Proxy Information 


Oc 


This field contains the parameter of the proxy. 


Route Information 


Oc 


This field contains the parameter of the route. 


Failed parameter 


Oc 


This field contains missing and/or unsupported parameter that caused the failure. 


Service Information 


Oc 


This field contains SMS specific information. 



Editor's Note: The mechanism to carry refund information is For Future Study. 



ETSI 



3GPP TS 32.274 version 9.0.0 Release 9 



29 



ETSI TS 132 274 V9.0.0 (2010-02) 



6.3 SMS charging specific parameters 

6.3.1 Definition of tine SIVIS cinarging information 

6.3.1 .1 SMS charging information assignment for Service-Information 

The components in the Service Information that are use for SMS charging can be found in table 6.3.1.1. 
Table 6.3.1.1 : Service Information used for SMS Charging 



Field 


Category 


Description 


Service Information 


Om 


This is a structured field and holds the 3GPP specific parameter as 
defined in TS 32.299 [50]. For SMS Charging the SMS-lnformation and 
selected parameters of MMS Information, PS-Information and IMS 
information are used. 


SIVIS Information 


Om 


This is a structured field and holds the SMS specific parameters. The 
details are defined in table 6.3.1 .2. 


MMS Information 


Om 


This is a structure field and the following parameters are specific to SMS. 
The complete structure is defined in 3GPP TS 32.270 [13] 


Originator Address 


Om 


This field holds the address of the originator of the SM. This will typically 
be an E.I 64 number or a shortcode. Multiple addresses may be carried if 
additional information is available, e.g. IMSI and E.I 64 number. 








Submission Time 


Oc 


This field holds the timestamp of when the submitted SM arrived at the 
originating SMS Node. The information to populate this field is obtained 
from the TP-Service-Center-Time-Stamp (TP-SCTS) as defined in 3GPP 
TS 23.040 [7]. If a refund or retransmission is required, the timestamp 
carries the timestamp associated with the original submitted SM. 


Priority 


Oc 


This field holds any priority information associated with an SM. 
Applicable to terminating procedures only. Priority handling is defined in 
3GPP TS 23.040 [13]. The value 'low' is not applicable. 


IVIessage Id 


Om 


This field carries the identity used to identify an SM in the SMS node 
associated with entity that submitted it. The information to populate this 
field is obtained from the TP-Message-Reference (TP-MR) as defined in 
3GPP TS 23.040 [7]. 


Message Size 


Om 


This field carries the length of the user data part of the SM. The 
information to populate this field is obtained from the TP-User-Data- 
Length (TP-UDL) as defined in 3GPP TS 23.040 [7] 


IVIessage Class 


Om 


Used as defined in 3GPP TS 32.270 [13]. It is implementation dependent 
the value selected for a specific transaction. 


Delivery Report Requested 


Oc 


This field indicates whether a delivery report is requested by the SM 
originator. The information to populate this field is obtained from the TP- 
Status-Report-Request (TP-SRR) as defined in 3GPP TS 23.040 [7] 


PS Information 


Oc 


This is a structured field and the following parameters are specific to SMS. 
The complete structure is defined in TS 32.251 [11]. 


PDP Address 


Oc 


This field holds the IP address used by the subscriber for the SMS 
transaction. Included if the SMS node is the IP-SM-GW. 


3GPP User Location Info 


Oc 


This field holds the information about the location of the subscriber during 
the SMS transaction. 


3GPP RAT Type 


Oc 


This field holds information about the radio access technology used for the 
SMS transaction. 


IMS Information 


Oc 


This is a structured field and the following parameters are specific to SMS. 
The complete structure is defined in TS 32.260 [15]. 


User Session Id 


Oc 


This field holds the session identifier. For a SIP session the Session-ID 
contains the SIP Call ID. 


Number Portability routing 
information 


Oc 


This field includes information on number portability after DNS/ENUM 
request from S-CSCF in the calling user"s home network. 


Carrier Select routing 
information 


Oc 


This field includes information on carrier select after DNS/ENUM request 
from S-CSCF in the calling user"s home network. 
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6.3.1 .2 Definition of the SMS Information 

The components in the SMS Information that are used for SMS charging can be found in table 6.3.1.2. 

Table 6.3.1.2: SMS Information used for SMS Charging 



Field 


Category 


Description 


SMS Node 


Om 


Identifies the SMS Node as IP-SM-GW or SMS Router or a combined IP-SM- 
GW / SMS Router or as SMS-SC. 


SM Client Address 


Om 


This field holds the address of the SMS node to which the charging system is 
connected to. This may be the same as the SMSC Address field. 


Originator SCCP Address 


Oc 


This field holds the SCCP calling address used to receive the SM at the SMS 
node. Only present if SMSIP is not used for the inward connection. 


Originator Received Address 


Oc 


This field holds the original, unmodified address of the originator of the SM, 
as received by the SMS node, in case address manipulation (such as 
number plan corrections) have been applied in the SMS node. This will 
typically be an E.I 64 number or a shortcode. Multiple addresses may be 
carried if additional information is available, e.g. IMSI and E.I 64 number. 


Recipient Info 


Oc 


This field holds recipient information for the SM. Each occurrence of this field 

denotes a different recipient. 

Multiple occurrences of this field are allowed in case 

- multiple recipients are associated with the charged event and 

- all other charging information is identical for all recipients. 

In case the SM contains a Delivery Report, as described in subclause 
5.3.2.3, this field identifies the recipient of this Delivery Report. This recipient 
information must correspond to the originator information of the message 
that triggered this Delivery Report. (Note 2) 


Recipient Address 


Oc 


This field holds the address of the recipient of the SM. This will typically be 
an E.164 number or a shortcode. Multiple addresses may be carried if 
additional information is available, e.g. shortcode or IMSI and E.164 number. 


Recipient Received Address 


Oc 


This field holds the original, unmodified address of the recipient of the SM, 
as received by the SMS node, in case address manipulation (such as 
number plan corrections) have been applied in the SMS node. This will 
typically be an E.164 number or a shortcode. Multiple addresses may be 
carried if additional information is available, e.g. shortcode or IMSI and E.164 
number. 


Recipient SCCP Address 


Oc 


This field holds the SCCP called address used by the SMS node to onward 
deliver the SM. Only present if SMSIP is not used for the outward 
connection. 


SIVI Destination Interface 


Om 


This is a structured field containing information describing the interface on 
which the SM is to be delivered (i.e. the next hop) 
In case the charging event is for person to application messaging or for 
application to application messaging (see subclause 5.1.1) this field holds 
the identification of the application. (See also Note 3) 


SIVI Protocol Id 


Oc 


This field holds the TP- PROTOCOL- ID (TP-PID) as defined in 3GPP TS 
23.040 [7]. This field relates to the recipient when charging MT SMS 
messages as specified in 32.240 [1]. 


SMSC Address 


Om 


This field holds the address of the SMSC to which the originating or 
terminating SM is directed to. 


SIVI Data Coding Scheme 


Om 


This field holds the data coding scheme used within the SM. The information 
to populate this field is obtained from TP-DCS header. 








SM Message Type 


Om 


This field identifies the message that triggered the generation of charging 
information. 


SM Originator Interface 


Om 


This is a structured field containing information describing the interface on 
which the SM was received by the SMS node (i.e. the previous hop) 
In case the charging event is for application to person messaging or for 
application to application messaging (see subclause 5.1.1) this field holds 
the identification of the application. (See also Note 3) 


SM Protocol Id 


Oc 


This field holds the TP- PROTOCOL- ID (TP-PID) as defined in 3GPP TS 
23.040 [7] This field relates to the originator when charging MO SMS 
messages as specified in 32.240 [1]. 


SM Reply Path Requested 


Oc 


This field carries an indication of whether a reply SM to an original SM shall 
follow the same path as identified by the TP-Reply-Path (TP-RP) flag. 


SM User Data Header 


Oc 


This field carries the user data header extracted from the user data of the 
SM. The user data header (TP-UDH) is specified in 3GPP TS 23.040 [7] 
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SM Status 


Oc 


This field holds the information from the TP-Status field in a Status-Report 
TPDU. This information is only applicable to delivery report charging 
procedures or where ECUR is employed. 


SM Discharge Time 


Oc 


This field holds the time associated with the event being reported in the SM 
Status field. This information is only applicable to delivery report charging 
procedures. 


Number of Messages Sent 


Oc 


Indicates the number of SMSs sent by the IMS application if applicable. 


SIVI Service Type 


Oc 


This field indicates the type of SM service that caused the charging 
interaction. It is only applicable for SM supplementary service procedures. 



NOTE 1 : The case of multi-destinations of SMS refers to SMS and Internet Electronic Mail interworking as 
specified in subsclause 3.8 of TS 23.040 [7] 

NOTE 2: Implementations vary as to the originator address that is presented to an end user for a Delivery Report. 
Typically the originator address either identifies the SMS node that generated the Delivery Report or the 
originator address of a Delivery Report identifies the recipient of the original message that triggered this 
Report. It is expected that the charging event contains the information presented to the end user. 

NOTE 3: There is a distinction between short numbers (as conveyed in originator and/or recipient address fields) 
and the identification of SM applications (as carried in SM Originator Interface and/or SM Destination 
Interface). Short numbers are used by end users to address a service of an applications. Multiple short 
numbers may map to one application capable of multiple services. The identification of an application is 
how an application is know to the operator. 

6.3.2 Formal parameter description 

6.3.2.1 SMS charging information for CDRs 

Editor"s Note: For Future Study. 

6.3.2.2 SMS charging information for charging events 

Editor"s Note: For Future Study. 
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